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£NJ ' Abstract 

, We take a critical look at the relationship between the security of cryptographic schemes in 

the Random Oracle Model, and the security of the schemes that result from implementing the 
random oracle by so called "cryptographic hash functions" . 

The main result of this paper is a negative one: There exist signature and encryption schemes 
that are secure in the Random Oracle Model, but for which any implementation of the random 
oracle results in insecure schemes. 

In the process of devising the above schemes, we consider possible definitions for the notion 
• of a "good implementation" of a random oracle, pointing out limitations and challenges. 
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1 Introduction 

A popular methodology for designing cryptographic protocols consists of the following two steps. 
One first designs an ideal system in which all parties (including the adversary) have oracle access 
to a truly random function, and proves the security of this ideal system. Next, one replaces the 
random oracle by a "good cryptographic hashing function" (such as MD5 or SHA), providing all 
parties (including the adversary) with a succinct description of this function. Thus, one obtains 
an implementation of the ideal system in a "real- world" where random oracles do not exist. This 
methodology, explicitly formulated by Bellare and Rogaway and hereafter referred to as the 
random oracle methodology, has been used in many works (see, for example, || 




Although the random oracle methodology seems to be useful in practice, it is unclear how to put 
this methodology on firm grounds. One can indeed make clear statements regarding the operation 
of the ideal system, but it is not clear what happens when one replaces the random oracle by a 
function that has a succinct description available to all parties. What one would have liked is (at 
least a definition of) a class of functions that, when used to replace the random oracle, maintains 
the security of the ideal scheme. The purpose of this work is to point out fundamental difficulties in 
proceeding towards this goal. We demonstrate that the traditional approach of providing a single 
robust definition that supports a wide range of applications is bound to fail. That is, one cannot 
expect to see definitions such as of pseudorandom generators or functions || and general 

results of the type saying that these can be used in any application in which parties are restricted 
merely by computing resources. Specifically, we identify a specific property of the random oracle, 
that seems to capture one aspect of the random oracle methodology (and in particular seems to 
underline heuristics such as the Fiat-Shamir transformation of a three-round identification scheme 
into a signature scheme in the We show that even a minimalistic formulation of this property, 
called correlation intractability, cannot be obtained by any fully specified function (or function 
ensemble) . 

To demonstrate the implications of the above to the security of cryptographic systems, we show 
that systems whose security relies on the "correlation intractability" of their oracle may be secure in 
the Random Oracle Model, and yet be insecure when implemented using any fully specified function 
(or function ensemble). In particular, we describe schemes for digital signatures and public- key 
encryption that are secure in the Random Oracle Model, but for which any implementation yields 
insecure schemes. This refutes the belief that a security proof in the Random Oracle Model means 
that there are no "structural flaws" in the scheme. 

1.1 The Setting 

For the purpose of the following discussion, a cryptographic system consists of a set of parties, 
which are modeled by probabilistic polynomial time interactive Turing machines. A cryptographic 
application comes with a security requirement specifying the adversary's abilities and when the latter 
is considered successful. The abilities of the adversary include its computational power (typically, 
an arbitrary polynomial-time machine) and the ways in which it can interact with the other parties. 
The success of the adversary is defined by means of a predetermined polynomial-time predicate of 
the application's global view^\ A system is considered secure if any adversary with the given abilities 
has only a negligible probability of success. 

1 The application's global view consists of the initial inputs of all the parties (including the adversary), their 
internal coin tosses, and all the messages which were exchanged among them. 
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1.1.1 The Random Oracle Model 



In a scheme that operates in the Random Oracle Model, all parties (including the adversary) interact 
with one another as usual interactive machines, but in addition they can make oracle queries. It is 
postulated that all oracle queries, regardless of the identity of the party making them, are answered 
by a single function, denoted O, that is uniformly selected among all possible functions. The set 
of possible functions is determined by a length function, ^ ut( - )) an d by the security parameter of 
the system. Specifically, given security parameter k we consider functions mapping {0, i}poiy(*0 
to {0, l}^° ut ( fc ). A set of interactive oracle machines as above corresponds to an ideal system for 
one specific application. Security of an ideal system is defined as usual. That is, an ideal system 
is considered secure if any adversary with the given abilities (including oracle access) has only a 
negligible probability of success. Here the probability is taken also over the choices of the random 
oracle. 

1.1.2 Implementing an ideal system 

Loosely speaking, by "implementing" a particular ideal system we mean using an easy-to-evaluate 
function / instead of the random oracle. That is, whenever the ideal system queries the oracle 
with a value x, the implementation instead evaluates f(x). Formally defining this notion, however, 
takes some care. Below we briefly examine (and discard of) the notion of implementation by a 
single function, and then present the notion of implementation by a function ensemble, which is 
the notion we use throughout the paper. 

Implementation by a single function. In accordance with the above discussion, each ideal 
system (for some specific application), II, is transformed into a real system (for the same applica- 
tion) by transforming each interactive oracle machine, into a standard interactive machine in the 
natural manner. That is, each oracle call is replaced by the evaluation of a fixed function / on the 
corresponding query.0 

The above system is called an implementation ofTL using function f. The adversary, attacking 
this implementation, may mimic the behavior of the adversary of the ideal system, by evaluating 
/ at arguments of its choice, but it needs not do so. In particular, it may obtain some global 
insight into the structure of the function /, and use this insight towards its vicious goals. An 
implementation is called secure if any adversary attacking it may succeed only with negligible 
probability, where the success event is defined exactly as in the ideal system (i.e., it is defined by 
the same polynomial-time computable predicate of the application's global view). 

Using this notion of an implementation, we would like to say that a function / is a "good 
implementation of a random oracle" if for any ideal system II, security of IT implies security of 
the implementation of II using /. It is very easy to see, however, that no (single) polynomial- 
time computable function can provide a good implementation of a random oracle. Consider, for 
example, a candidate function /. Then, a (contrived) application for which / does not provide 
a good implementation consists of an oracle machine (representing an honest party) that upon 
receiving a message m, makes query m to the oracle and reveals its private input if the oracle 
answers with f(m). Suppose that the adversary is deemed successful whenever the honest party 
reveals its private input. Clearly, this ideal system is secure (in the Random Oracle Model), 

2 Formally, the function / also takes as input the security parameter k, so that the function /&(■) = £ f(k, •) maps 
{ ,1}P°W» to {0,1}*°^. 
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since the random oracle will return the value f(m) only with negligible probability; however, its 
implementation using / is certainly not secure. 

Implementation by a function ensemble. In face of the failure of the above naive attempt, 
a more sophisticated interpretation is indeed called for. Here one considers the substitution of the 
random oracle by a function randomly selected from a collection of functions. In this setting, we 
have a "system set-up" phase, in which the function is selected once and for all, and its description 
is available to all parties.^] After this set-up phase, this function is used in place of the random 
oracle just as above. A little more precisely, we consider a function ensemble J- = {F^\k E N}, 
where 

F k = {/,:{0,l} poly ( fe ^{0,l}^( fc )} se{0jl}fc , 

such that there exists a polynomial time algorithm that, on input s and x, returns f s (x). The 
implementation of an ideal system, II, by the function ensemble T is obtained as follows. On 
security parameter k, we uniformly select s £ {0, l} k , and make s available to all parties including 
the adversary. Given this initialization phase, we replace each oracle call of an interactive oracle 
machine by the evaluation of the function f s on the corresponding query. The resulting system is 
called an implementation of II using function ensemble T . 

Again, the adversary may (but need not necessarily) mimic the behavior of the adversary in 
the Random Oracle Model by evaluating f s at arguments of its choice. Such a real system is 
called secure if any adversary attacking it has only a negligible probability of success, where the 
probability is taken over the random choice of s as well as the coins of all the parties. As before, we 
would like to say that an ensemble T provides a "good implementation of a random oracle" if for 
every ideal system II, if II is secure then so is the implementation of II using T. Notice that in this 
case, the contrived example from above does not work anymore, since the success event must be 
independent of the random choice of s. Nonetheless, this work implies that no function ensemble 
can provide a good implementation of a random oracle. We elaborate in the next subsection. 

1.2 Our Results 

1.2.1 Correlation intractability. 

One property we certainly expect from a good implementation of a random oracle is that it should 
be infeasible to find inputs to the function that stand in some "rare" relationship with the cor- 
responding outputs. Indeed, many applications of the random-oracle methodology (such as the 
Fiat-Shamir heuristic) assume that it is infeasible to find an input-output pair that stands in a 
particular relations induced by the application. Trying to formulate this property, we may require 
that given the description of the function it is hard to find a sequence of preimages that together 
with their images (under this function) satisfy some given relation. Clearly, this can only hold for 
relations for which finding such sequences is hard in the Random Oracle Model. That is, if it is 
hard to find a sequence of preimages that together with their images under a random oracle satisfy 
relation R, then given the description of a "good" function f s it should be hard to find a sequence 
of preimages that together with their images under f s satisfy R. 

In fact, we mainly consider the task of finding a single preimage that together with its image 
satisfies some property. Loosely speaking, a relation is called evasive if when given access to a 
random oracle O, it is infeasible to find a string x so that the pair (x, 0(x)) is in the relation. (For 

3 In the sequel we consider examples of public key signature and encryption schemes. In these schemes, the 
initialization (set-up) step is combined with the key-generation step of the original scheme. 
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instance, the relation {(x,0 iout ^) : x G {0,1}*} is evasive. The relation {(x,0y) : x £ {0,1}*, y E 
{0, l}^°ut( fc ) _1 } i s not.) A function ensemble T (as above) is called correlation intractable if for every 
evasive relation, given the description of a uniformly selected function f s G Fk it is infeasible to 
find an x such that (x, f s (x)) is in the relation. We show that 

Informal Theorem 1.1 There exist no correlation intractable function ensembles. 

Restricted correlation intractability. The proof of the above negative result relies on the fact 
that the description of the function is shorter than its input. Thus we also investigate the case 
where one restricts the function f s to inputs whose length is less than the length of s. We show 
that the negative result can be extended to the case where the function description is shorter than 
the sum of the lengths of the input and output of the function. (Furthermore, if one generalizes 
the notion of correlation intractability to relations on sequences of inputs and outputs, then the 
negative result holds as long as the total length of all the inputs and outputs is more than the length 
of the function description.) This still leaves open the possibility that there exist function ensembles 
that are correlation intractable with respect to input-output sequences of a-priori bounded total 
length. See further discussion in Section [|. 

1.2.2 Failure of the Random Oracle Methodology 

Upon formulating the random oracle methodology, Bellare and Rogaway did warn that a proof 
of security in the Random Oracle Model should not be taken as guarantee to the security of 
implementations (in which the Random Oracle is replaced by functions such as MD5) (T|. However, 
it is widely believed that a security proof in the Random Oracle Model means that there are no 
"structural flaws" in the scheme. That is, any attack against an implementation of this scheme 
must take advantage of specific flaws in the function that is used to implement the oracle. In this 
work we demonstrate that these beliefs are false. Specifically, we show that 

Informal Theorem 1.2 There exists encryption and signature schemes that are secure in the 
Random Oracle Model, but have NO secure implementation in the real model (where a Ran- 
dom Oracle does not exist). That is, implementing these secure ideal schemes, using any function 
ensemble, results in insecure schemes. 

The encryption and signature schemes presented to prove Theorem [E^ are "unnatural" . We do not 
claim (or even suggest) that a statement as above holds with respect to schemes presented in the 
literature. Still, the lesson is that the mere fact that a scheme is secure in the Random Oracle Model 
does not necessarily imply that a particular implementation of it (in the real world) is secure, or 
even that this scheme does not have any "structural flaws" . Furthermore, unless otherwise justified, 
such ideal scheme may have no secure implementations at all. 

In fact, our techniques are quite general and can be applied to practically any cryptographic 
application. That is, given an ideal cryptographic application A, we can construct an ideal cryp- 
tographic application A' such that A' is just as secure as A (in the Random Oracle Model), but 
A' has no secure implementation. Hence, in this sense, security of an ideal system in the Random 
Oracle Model is a bad predictor of the security of an implementation of the system in real life. 
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1.3 Techniques 



Our proof of Theorem 1.2 uses in an essential way non-interactive CS-proofs (in the Random 
Oracle Model), as defined and constructed by Micali [21|.Q Interestingly, we only use the fact 
that non-interactive CS-proofs exist in the Random Oracle Model, and do not care whether or not 
these ideal CS-proofs have an implementation using any function ensembles (nor if non-interactive 
CS-proofs exists at all outside of the Random Oracle Model). Specifically, CS-proofs are used to 
"effectively verify" any polynomial-time verifiable statement within time that is bounded by one 
fixed polynomial. Furthermore, we use the fact that the definition of CS-proofs guarantees that the 
complexity of generating such proofs is polynomial in the time required for ordinary verification. 



See further discussion in Section 2.2 



1.4 Related Work 

Correlation intractability. Our definition of correlation-intractability is related to a definition 
by Okamoto [25]. Using our terminology, Okamoto considers function ensembles for which it is 
infeasible to form input-output relations with respect to a specific evasive relation p5| , Def. 19] 
(rather than all such relations). He uses the assumption that such function ensembles exists, for a 
specific evasive relation in |25|, Thm. 20]. 



Special-purpose properties of the Random Oracle Model. First steps in the direction 
of identifying and studying useful special-purpose properties of the Random Oracle Model have 
been taken by Canetti M. Specifically, Canetti considered a property called "perfect one-wayness" , 
provided a definition of this property, constructions which possess this property (under some rea- 
sonable assumptions), and applications for which such functions suffice. Additional constructions 
have been suggested by Canetti, Micciancio and Reingold Q. Another context where specific prop- 
erties of the random oracle where captured and realized is the signature scheme of Gennaro, Halevi 
and Rabin JT0|]. 

Relation to Zero-Knowledge proofs. Following the preliminary version of the current work ||, 
Hada and Tanaka observed that the existence of even restricted correlation intractable functions 
(in the non uniform model) would be enough to prove that 3-round auxiliary-input zero-knowledge 
AM proof systems only exist for languages in BPP Jig)] . (Recall that auxiliary-input zero-knowledge 



is seemingly weaker than black-box zero-knowledge, and so the result of [18| is incomparable to 



prior work of Goldreich and Krawczyk [14] that showed that constant-round auxiliary- input zero- 



knowledge AM proof systems only exist for languages in BPP.) 



Relation to "magic functions" . More recently, Dwork et. al. investigated the notion of "magic 
functions" , which is related to our correlation intractable functions || . Like correlation intractabil- 
ity, the definition of "magic functions" is motivated by the quest to capture the properties that are 
required from the hash function in the Fiat-Shamir heuristic. Correlation intractability seems like 
a general and natural property, but is not known to be either necessary or sufficient for the Fiat- 
Shamir heuristic (which is a special case of the random oracle methodology). In contrast, "magic 
functions" are explicitly defined as "functions that make the Fiat-Shamir heuristic work" . In their 

4 The underlying ideas of Micali's construction [^J can be traced to Kilian's construction and to the Fiat- 
Shamir transformation § (which is sound in the Random Oracle Model). 
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paper ||, Dwork et. al. demonstrated a relation between "magic functions" and 3-round zero- 
knowledge, which is similar to the relation between correlation intractability and zero-knowledge 
exhibited in [18|. Specifically, they showed that the existence of "magic functions" implies the 
non-existence of some kind of 3-round zero-knowledge proof systems, as well as a weakened version 
of a converse theorem. 



1.5 Organization 

Section || presents syntax necessary for the rest of the paper as well as review the definition of CS- 
proofs. Section || discusses the reasoning that led us to define the correlation intractability property, 
and prove that even such a minimalistic definition cannot be met by a function ensemble. Section |] 
presents our main negative results - demonstrating the existence of secure ideal signature and 
encryption schemes that do not have secure implementations. Restricted correlation intractability 
is defined and studied in Section ||. Three different perspectives on the results obtained in this 
paper are presented in Section ||. 



2 Preliminaries 

We consider probability spaces defined over executions of probabilistic machines. Typically, we 
consider the probability that an output generated by one machine M\ satisfies a condition that 
involves the execution of a second machine M%. For example, we denote by Pr[y <— M\(x) , \y\ = 
\x\ SzM2(y) = 1] the probability that on input x, machine M\ outputs a string that has length \x\ 
and is accepted by machine M2. That is, y in the above notation represents a random variable that 
may be assigned arbitrary values in {0, 1}*, conditions are made regarding this y, and we consider 
the probability that these conditions are satisfied when y is distributed according to M\{x). 



2.1 Function Ensembles 

To make the discussion in the Introduction more precise, we explicitly associate a length function, 
^out : N— >N, with the output of the random oracle and its candidate implementations. We always 
assume that the length functions are super-logarithmic and polynomially bounded (i.e. u)(\ogk) < 
^out(k) < poly(fc)). We refer to an oracle with length function £ out as an £ out -oracle. On security 
parameter k, each answer of the oracle is a string of length £ ut(k). A candidate implementation 
of a random £ out -oracle is an ^ ou t-ensemble as defined below. 

Definition 2.1 (function ensembles) Let £ out : N— >N be a length function. An £ out -ensemble is 

a sequence T = {Fk}k£N of families of functions, = {f s : {0, 1}* — > {0, l}^ out ^} se {o,i} fc > so that 
the following holds 

Length requirement. For every s G {0, l} k and every x G {0, 1}*, |/ s (x)| = ^out(^)- 

Efficiency requirement. There exists a polynomial-time algorithm EvAL so that for every s,x € 
{0,1}*, it holds that Eval(s,x) = f s (x). 

In the sequel we often call s the description or the seed of the function f s . 



Remark 2.2 The length of the seed in the above definition serves as a "security parameter" and 
is meant to control the "quality" of the implementation. It is important to note that although f s (-) 
is syntactically defined on every input, in a cryptographic applications it is only used on inputs of 
length at most poly(|s|). We stress that all results presented in this paper refer to such usage. 
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Remark 2.3 One may even envision applications in which a more stringent condition on the 
use of f s holds. Specifically, one may require that the function f s be only applied to inputs of 
length at most An(|s|), where l- m : N— >N is a specific (polynomially bounded) length function (e.g., 
^in(k) = 2k). We discuss the effects of making such a stringent requirement in Section ||. 

2.2 CS Proofs 

Our construction of signature and encryption schemes that are secure in the Random Oracle Model 
but not in the "real world" uses CS-proofs as defined and constructed by Micali [21]. Below, we 
briefly recall the relevant definitions and results. 

A CS-proof system consists of a prover, Prv, that is trying to convince a verifier, Ver, of the 
validity of an assertion of the type machine M accepts input x within t steps^ The central feature 
of CS-proofs is that the running-time of the prover on input x is (polynomially) related to the 
actual running time of M(x) rather than to the global upper bound t; furthermore, the verifier's 
running-time is poly-logarithmic related to t. (These conditions are expressed in the additional 



efficiency requirements in Definition 2.4 below.) 

In our context, we use non-interactive CS-proofs that work in the Random Oracle Model; that 
is, both prover and verifier have access to a common random oracle. The prover generates an alleged 
proof that is examined by the verifier. A construction for such CS-proofs was presented by Mi- 
cali pi]]) using ideas that can be traced to Kilian's construction p0|, and requires no computational 



assumptions. Following is the formulation of CS-proofs, as defined in [21]. 

In the formulation below, the security parameter k is presented in unary to both parties, whereas 
the global time bound t is presented in unary to the prover and in binary to the verifier. This allows 
the (polynomial-time) prover to run in time polynomial in t, whereas the (polynomial-time) verifier 
may only run in time that is poly-logarithmic in t. (Observe that it is not required that t is bounded 
above by a polynomial in \x\. In fact, in our arguments, we shall use a slightly super-polynomial 
function t (i.e., t(n) = n logn ).) Finally, we mention that both the prover and the verifier in the 



definition below are required to be deterministic machines. See some discussion in Remark 2.6 
below. 

Definition 2.4 (Non-interactive CS proofs in the Random Oracle Model) A CS-proof sys- 
tem consists of two (deterministic) polynomial-time oracle machines, a prover Prv and a verifier 
Ver, which operate as follows: 

• On input (l k , (M),x, l t ) and access to an oracle O, the prover computes a proof -k = PRV C '(l fc , (M), x, 1* 
such that \ir\ = poly(/c, |(M)|, \x\, log t). 



On input (l k , (M), x, t, tt), with t encoded in binary, and access to O, the verifier decides 
whether to accept or reject the proof tt (i.e., VER C '(l fc , (M),x,t,n) € {accept, reject}). 



The proof system satisfies the following conditions, where the probabilities are taken over the random 
choice of the oracle O: 

Perfect completeness: For any M, x, t such that machine M accepts the string x within t steps, and 
for any k, 

pr [ n<-Pm°(l k ,(M),x,l t ), 
O VER°(l fc , (M},x,t,Tr) = accept 



5 When t is presented in binary, such valid assertions form a complete language for the class (deterministic) 
exponential time. 
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Computational soundness: For any polynomial time oracle machine Bad and any input w 
((M),x, 1*) such that M does not accepts x within t steps, it holds that 



Pr 

o 



vr <- BAD°(l*,(M),z,l*), 
Ver c '(1 /c , (M),x,t,ir) = accept 



< 



poly(k + \w\) 
2* 



Additional efficiency conditions:^] The running-time of the prover Pry on input (l fc , (M),x, 1*) is 
(polynomially) related to the actual running time of M{x), rather than to the global upper 
bound t. That is, there exists a fixed polynomial p(-), such that 

T PRV (l fc ,(M),x,l') <p(k,wm{t,T M (x)}) 

where Ta(x) denotes the running time of machine A on input x. 



Remark 2.5 (Oracle output length) The above definition does not specify the output length 
of the oracle (i.e., the length of the answers to the oracle queries). In some cases it is convenient 
to identify this output length with the security parameter, but in many case we do not follow this 
convention (e.g., in Proposition |2.8| below). In any case, it is trivial to implement an oracle with 
one output length given an oracle with different output length, so we allow ourselves to ignore this 
issue. 



Remark 2.6 (Deterministic verifier) Recall that Definition 2.4 mandates that both the prover 
and verifier are deterministic. Indeed this deviates from the tradition (in this area) of allowing 
the verifier to be probabilistic; but Micali's construction (in the Random Oracle Model) happens 
to employ a deterministic verifier (cf. |]2l|| ). This issue is not essential to our main results, but 
plays an important role in the proof of Proposition 5.7 (due to K. Nissim). We note that when 
working in the Random Oracle Model (and only caring about completeness and soundness), one may 
assume without loss of generality that the prover is deterministic (because it can obtain adequate 
randomness by querying the oracle). This does not hold with respect to the verifier, since its coin 
tosses must be unknown to the prover. 



Theorem 2.7 (Micali |2l|| ) There exists a non-interactive CS proof system in the Random Oracle 
Model. 



For the proof of our construction (Theorem iA), we will need a different soundness condition 



than the one from above. Specifically, we need to make sure that given the machine M (and the 
complexity bound t), it is hard to find any pair (x,tt) such that M does not accept x within t 
steps and yet Ver will accept ir as a valid CS-proof to the contrary. One way to obtain this 
soundness property from the original one, is by postulating that when the verifier is given a proof 
for an assertion w = ((M),x,t), it uses security parameter k + \w\ (rather than just k). Using a 
straightforward counting argument we get: 

6 By the above, the running time of Prv on input (l fc , (M),x, 1*) is at most poly(fc, |(M)|, |x|,t), whereas the 
running time of Ver on input (l fc , (M),x, i,7r) is at most poly(fc, \ {M) |, \x\, |tt|, log t). The following condition provide 
even lower running time bound for the prover. 
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Proposition 2.8 Let (Prv, Ver) be a CS proof system. Then for every polynomial time oracle 
machine Bad, there exists a polynomial q(-), such that for every k it holds that 

BAD°(l fc ), where w = ((M),x,t), 
s.t. machine M does not accept x within t steps < 
and yet VER (l fe+ l w l, w, n) = accept 



ebad(fe) = f Pr 



2 k 



3 Correlation Intractability 

In this section we present and discuss the difficulty of defining the intuitive requirement that a 
function ensemble "behaves like a random oracle" even when its description is given. In particular, 
we show that even some minimalistic definitions cannot be realized. 



An obvious failure. We first comment that an obvious maximalistic definition, which amount 
to adopting the pseudorandom requirement of (13], fails poorly. That is, we cannot require that 
an (efficient) algorithm that is given the description of the function cannot distinguish its input- 
output behavior from the one of a random function, because the function description determines 
its input-output behavior. 



Towards a minimalistic definition. Although we cannot require the value of a fully specified 
function to be "random", we may still be able to require that it has some "unpredictability prop- 
erties". For example, we may require that, given a description of a family and a function chosen 
at random from a this family, it is hard to find two preimages that the function maps to the same 
image. Indeed, this sound definition coincides with the well-known collision-intractability property 
Trying to generalize, we may replace the "equality of images" relation by any other relation 
among the pre-images and images of the function. Namely, we would like to say that an ensemble 
is correlation intractable if for any relation, given the description of a randomly chosen function, 
it is infeasible to find a sequence of preimages that together with their images satisfy this relation. 

This requirement, however, is still unreasonably strong since there are relations that are easy to 
satisfy even in the Random Oracle Model. We therefore restrict the above infeasibility requirement 
by saying that it holds only with respect to relations that are hard to satisfy in the Random Oracle 
Model. That is, if it is hard to find a sequence of preimages that together with their images under 
a random function satisfy relation R, then given the description of a randomly chosen function f s 
it should be hard to find a sequence of preimages that together with their images under f s satisfy 
R. 

This seems to be a minimalistic notion of correlation intractable ensemble of functions, yet we 
show below that no ensemble can satisfy it. In fact, in the definition below we only consider the 
task of finding a single preimage that together with its image satisfies some property. Namely, 
instead of considering all possible relations, we only consider binary ones. Since we are showing 
impossibility result, this syntactic restriction only strengthens the result. 

3.1 Actual Definitions 

We start with a formal definition of a relation that is hard to satisfy in the random oracle model. 

Definition 3.1 (Evasive Relations) A binary relation R is said to be evasive with respect to 
length function £ ont if for any probabilistic polynomial time oracle machine M 

Pi[x ^ M°(l k ), (x,0(x))eR] = negl(fc) 
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where O : {0, 1}* — > {0, l}^° ut ( fe ) is a uniformly chosen function and negl(-) is a negligible function]^ 

A special case of evasive relations consists of i?'s for which there exists a negligible function negl(-) 
so that for all k 

max < Pr \(x,y)£R] > = neglfA;) 
xe{o,i}* \ tf e{o,l}Wk) lv ,yj J J &y J 

(All the binary relations used in the sequel falls into this category.) The reason such an R is evasive 
is that any oracle machine, M, making at most poly(/c) queries to a random O satisfies 

Pr[x <- M°(l fc ), (x,0(x))€R] < poly(Jfe) • max J Pr[(x, 0(z)) G i?] } 

< poly(fc) • negl(fc) 

We are now ready to state our minimalistic definition of a correlation intractable ensemble: 

Definition 3.2 (Correlation intractability) Let £ out : N — > N be length function, and let T be 
an £ on t -ensemble. 

• Let R C {0, 1}* x {0, 1}* be a binary relation. We say that T is correlation intractable with 

respect to R if for every probabilistic polynomial-time machine M it holds that 

Pr [x <- M(s), (x, f s {x)) ER] = neg\(k) 

s£{0,l} k 

where negl(-) is a negligible function, and the probability is taken over the choice of s G {0, l} k 
and the coins of M. 

• We say that T is correlation intractable if it is correlation intractable with respect to every 
evasive (w.r.t. l oa t) relation, 

Remark 3.3 In the above definition we quantify over all evasive relations. A weaker notion, called 
weak correlation intractability, is obtained by quantifying only over all polynomial-time recognizable 
evasive relations (i.e., we only consider those relations R such that there exists a polynomial time 
algorithm that, given (x,y), decides whether or not (x, y) E R). In the sequel we consider both 
notions. 

3.2 Correlation-intractable ensembles do not exist 

Theorem 3.4 There exist no correlation intractable ensembles, not even in the weak sense. 

Proof: Let £ OVL t be a length function and let T = {f s } be an ^ out -ensemble. We define the binary 
relation: 

R T = \j{(sj s (s)):s£{0,l} k } (1) 

k 

Clearly, this relation is polynomial-time recognizable, since f s can be computed in polynomial 
time. Also, the relation is evasive (w.r.t. ^ ut) since for every x € {0, 1}* there is at most one 
y € {0, iy°ut( k ) satisfying (x,y) G R r , an d so 

Pr[(x,y) G R r ] < 2^° ut W = 2~^°^ = neg\(k) . 
y 

7 A function /i: N R is negligible if for every positive polynomial p and all sufficiently large n's, fi(n) < l/p(n). 

8 Such a y exists if and only if £ ou t(|i|) = ^out(fc). 
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On the other hand, consider the machine / that computes the identity function, I(x) = x for all x. 
It violates the correlation intractability requirement, since for all k, 

Pr [(I(s)J s (I(s))) e B^} = Pr [(«,/,(«)) Gif] = 1. 
se{o,i} fc se{o,i} fc 

In fact, since is polynomial-time recognizable, even the weak correlation intractability of J- is 
violated. ■ 



4 Failure of the Random Oracle Methodology 

This section demonstrates that the security of a cryptographic scheme in the Random Oracle Model 
does not always imply its security under some specific choice of a "good hash function" that is used 
to implement the random oracle. To prove this statement we construct signature and encryption 
schemes, which are secure in the Random Oracle Model, yet for which any implementation of the 
random oracle yield insecure schemes. Put in other words, although the ideal scheme is secure, any 
implementation of it is necessarily insecure. 

The underlying idea is to start with a secure scheme (which may or may not use a random 
oracle) and modify it to get a scheme that is secure in the Random Oracle Model, but such that its 
security is easily violated when trying to replace the random oracle by any ensemble. This is done 



by using evasive relations as constructed in Theorem 3.4. The modified scheme starts by trying 
to find a preimage that together with its image yields a pair in the evasive relation. In case the 
attempt succeeds, the scheme does something that is clearly insecure (e.g., output the secret key). 
Otherwise, the scheme behaves as the original (secure) scheme does. The former case (i.e., finding 
a pair in the relation) will occur rarely in the Random Oracle Model, thus the scheme will maintain 
its security there. However, it will be easy for an adversary to make sure that the former case 
always occurs under any implementation of the Random Oracle Model, thus no implementation 
may be secure. We start with the case of a signature scheme, and present the construction in three 
steps. 

• In the first step we carry out the above idea in a naive way. This allows us to prove a weaker 
statement, saying that for any function ensemble J-, there exists a signature scheme that is 
secure in the Random Oracle Model, but is not secure when implemented using T . 

This, by itself, means that one cannot construct a function ensemble that provides secure 
implementation of any cryptographic scheme that is secure in the Random Oracle Model. 
But it does not rule out the possibility (ruled out below) that for any cryptographic scheme 
that is secure in the Random Oracle Model there exists a secure implementation (via a 
different function ensemble). 

• In the second step we use diagonalization techniques to reverse the order of quantifiers. 
Namely, we show that there exists a signature scheme that is secure in the Random Oracle 
Model, but for which any implementation (using any function ensemble) results in an inse- 
cure scheme. However, the scheme constructed in this step utilizes signing and verification 
procedures that run in (slightly) super-polynomial time. 



In the third step we use CS-proofs |2lJ to get rid of the super-polynomial running-time (of 
the legitimate procedures), hence obtaining a standard signature scheme that is secure in 
the Random Oracle Model, but has no secure implementation. Specifically, in this step we 
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use CS-proofs as a tool to "diagonalize against all polynomial-time ensembles in polynomial 
time". (As noted by Silvio Micali, this technique may be useful also in other settings where 
diagonalization techniques are applied.) 

The reader is referred to |[(| for basic terminology regarding signature schemes and corresponding 
notions of security. As a starting point for our constructions, we use a signature scheme, denoted 
S = (G,S,V), where G is the key-generation algorithm, S is the signing algorithm, and V is the 
verification algorithm. We assume that the scheme (G, S, V) is existentially unforgeable under 
adaptive chosen message attack, in the Random Oracle Model. We do not need to rely on any com- 
putational assumptions here, since one-way functions are sufficient for constructing secure signature 
schemes l27j, and the random oracle can be used to implement one-way functions without any 
assumptions 



Conventions. In the three steps below we assume, without loss of generality, that the security 
parameter (i.e., k) is implicit in the keys generated by G(l k ). Also, let us fix some length function 
^out : N— >N, which would be implicit in the discussions below (i.e., we assume that the random 
oracles are all £ ou t-oracles, the relations are evasive w.r.t. l on t, etc.). 

4.1 First Step 

Definition. Let S = (G,S,V) be a signature scheme (which may or may not use a random 
oracle), and let R be any binary relation, which is evasive w.r.t. length function i OVL f Then, by 
Sr = (G, Sr, Vr) we denote the following modification of S which utilizes a random £ out -oracle: 

Modified signature, S^(sk, msg), of message msg using signing key sk: 

1. If (msg, O(msg)) E R, output (sk, msg). 

2. Otherwise (i.e., (msg, O(msg)) $.R), output S (sk, msg) . 

Modified verification, V^(vk, msg, a), of alleged signature a to msg using verification key vk: 

1. If (msg, O(msg)) eR then accept 

2. Otherwise output V°(yk, msg, a). 

The key-generation algorithm, G, is the same as in the original scheme S. Item 1 in the sign- 
ing/verification algorithms is a harmful modification to the original signature scheme. Yet, if R is 
evasive, then it has little effect on the ideal system, and the behavior of the modified scheme is 
"indistinguishable" from the original one. In particular, 

Proposition 4.1 Suppose that R is evasive (w.r.t. £ on t) an d that S is existentially unforgeable un- 
der a chosen message attack in the Random Oracle Model. Then Sr is also existentially unforgeable 
under a chosen message attack in the Random Oracle Model. 

Proof: The intuition is that since R is evasive, it is infeasible for the forger to find a message 
m so that (m, 0{m)) G R. Thus, a forgery of the modified scheme must be due to Item (2), which 
yields a breaking of the original scheme. 



9 Alternatively, we could use an 'ordinary' signature scheme, but then our Theorem 4.4 would be conditioned on 
the existence of one-way functions. 



12 



Formally, let Ar be an adversary who mounts an adaptive chosen message attack on Sr, and 
whose success probability in obtaining an existential forgery (in the Random Oracle Model) is 
ef rg = €{ rg (k). Assume, toward contradiction, that ef rg is not negligible in the security parameter k. 

Denote by REL the event in which during an execution of ^4^, it hands out a message m for 
which (m,0(m)) G R (either as a query to the signer during the chosen message attack, or as 
the message for which it found a forgery at the end), and let e re i = e re i(A;) be the probability of 
that event. Using the hypothesis that R is evasive, we prove that e re \ is negligible in the security 
parameter k. Suppose, to the contrary, that e re i is not negligible. Then, we can try to efficiently 
find pairs (x,0(x)) G R by choosing a key-pair for S, and then implementing the attack, playing 
the role of both the signer algorithm and the adversary Ar. With probability e re i, one of Ars 
messages during this attack satisfies (m, 0(mj) Gi?, so just choosing at random one message that 
was used and outputting it yields a success probability of e Te \/q (with q being the number of different 
messages that are used in the attack). If e re i is not negligible, then neither is e Te \/q, contradicting 
the evasiveness of R. 

It is clear that barring the event REL, the execution of Ar against the original scheme S would 
be identical to its execution against Sr. Hence the probability that Ar succeeds in obtaining an 
existential forgery against S is at least ef rg — e re \. Since e re i is negligible, and €f rg is not, then Ars 
probability of obtaining an existential forgery against S is also not negligible, contradicting the 
assumed security of S. I 



The modification enables to break the modified scheme when implemented with a real ensemble J-, 
in the case where R is the relation R^ from Proposition 3.4. Indeed, as corollary to Propositions 3.4 



and 4.1, we immediately obtain: 



Corollary 4.2 For every efficiently computable l ou t-ensemble T ', there exists a signature scheme 
that is existentially unforgeable under a chosen message attack in the Random Oracle Model, yet 
when implemented with T , the resulting scheme is totally breakable under an adaptive chosen mes- 
sage attack, and existentially forgeable under a key-only attack. 



Proof: When we use an ensemble T to implement the random oracle in the scheme Sr, we obtain 
the following real scheme (which we denote S' R = (G', S R , V R )): 

G'(l k ): Uniformly pick s G {0, l} fc , set (sk, vk) «- G f °(l k ), and output ((sk, s), (vk, a)). 
S"^((sk,s),msg): Output S f R (sk, msg). 
V^((vk, s), msg, a): Output V^ s (vk, msg, a). 

Consider now what happens when we use the ensemble J- to implement the the scheme S r t (recall 
the definition of R from Eq. (|l|)). Since R? is evasive, then from Proposition 4.1 we infer that the 



S r t is secure in the Random Oracle Model. However, when we use the ensemble T to implement 
the scheme, the seed s becomes part of the public verification-key, and hence is known to the 
adversary. The adversary can simply output the pair (s,e), which will be accepted by V' RT as 
a valid message-signature pair (since (s,f s (s)) G R^). Hence, the adversary achieves existential 
forgery (of S' R r) under key-only attack. Alternatively, the adversary can ask the legitimate signer 
for a signature on s, hence obtaining the secret signing-key (i.e., total forgery). H 
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4.2 Second Step 

Enumeration. For this (and the next) subsection we need an enumeration of all efficiently com- 
putable function ensembles. Such enumeration is achieved via an enumeration of all polynomial- 
time algorithms (i.e., candidates for evaluation algorithms of such ensembles). Several standard 
technicalities arise. First, enumerating all polynomial-time algorithms is problematic since there 
is no single polynomial that bounds the running time of all these algorithms. Instead, we fix 
an arbitrary super-polynomial proper complexity function^, t : N — > N (e.g., t(n) = n logn ), and 
enumerate all algorithms of running-time bounded by t. The latter is done by enumerating all 
possible algorithms, and modifying each algorithm by adding a time-out mechanism that termi- 
nates the execution in case more than t(|input|) steps are taken. This modification does not effect 
the polynomial-time algorithms. Also, since we are interested in enumerating ^ ou t-ensembles, we 
modify each function by viewing its seed as a pair (s,x) (using some standard parsing ruleP]) and 
padding or truncating its output to length ^out ( I s I ) • Again, this modification has no effect on the 
^ ou t-ensembles. 

Let us denote by J- 1 the z th function ensemble according to the above enumeration, and denote 
by fl the function indexed by s from the ensemble J- 1 . Below we again use some standard rule for 
parsing a string a as a pair (i, s) and viewing it as a description of the function /]. 

Universal ensemble. Let hi = {Uk}k&t denote the "universal function ensemble" that is induced 
by the enumeration above, namely Uk = {^j jS )}/j jS \ 6 r 0) n*; and u^^(x) = fl(x). There exists a 
machine that computes the universal ensemble hi and works in slightly super-polynomial time, t. 

Universal relation. Denote by R u the universal relation that is defined with respect to the 
universal ensemble hi similarly to the way that R^ is defined with respect to any ensemble T . That 
is: 

R" = U{((i,s),m,s)i) ■ (i,s) € {0,l} fc } 



Or, in other words: 



(x,y)eR 



u y = u x (x) 

(i.e., x = (i, s) and y = f l s (x)) 



Modified signature scheme. Let S = (G,S,V) be a signature scheme (as above). We then 
denote by S u = (G, S u , V u ) the modified signature scheme that is derived by using R u in place of 
R in the previous construction. Specifically: 

Sf(sk,msg) d = 

1. If (msg, 0(msg)) £ R u (i.e., if msg = (i,s) and O(msg) = /](msg)) then output (sk,msg). 

2. Otherwise, output S (sk, msg) 

K°( vk > m sg, ct) d = 

1. If (msg, 0(msg)) £ R u then accept. 

2. Otherwise, output V°(vk, msg, a). 

10 Recall that t(n) is a proper complexity function (or time-constructible) if there exists a machine that computes 
t(n) and works in time 0(t(n)). This technical requirement is needed to ensure that the enumeration itself is 
computable in time 0(t(n)). 

11 For example, using a prefix-free code C, we can encode a pair (s,x) by C(s) concatenated with x. 
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We note that since these signature and verification algorithms need to compute U, they both run 
in time 0(t), which is slightly super-polynomial. 



Proposition 4.3 Suppose that S is existentially unforgeable under a chosen message attack in the 
Random Oracle Model. Then S u is also existentially unforgeable under a chosen message attack in 
the Random Oracle Model, but implementing it with any function ensemble yields a scheme that is 
totally breakable under chosen message attack and existentially forgeable under key-only attack. 



Proof: Since R u is evasive, then from Proposition H7P it follows that S u is secure in the Random 
Oracle Model. On the other hand, suppose that one tries to replace the random oracle in the 
scheme by an ensemble J- 1 (where i be the index in the enumeration). An adversary, given a seed s 
of a function in T l can then set msg = (i, s) and output the pair (msg, e), which would be accepted 
as a valid message-signature pair by V u . Alternatively, it can ask the signer for a signature on this 
message msg, and so obtain the secret signing-key. ■ 

4.3 Third step 

We now use CS-proofs to construct a new signature scheme that works in the Random Oracle 



Model. This construction is similar to the one in Subsection 4.2, except that instead of checking 
that (msg,0(msg)) € R u , the signer /verifier gets a CS-proof of that claim, and it only needs to 
verify the validity of that proof. Since verifying the validity of a CS-proof can be done much more 
efficiently than checking the claim "from scratch", the signing and verifications algorithms in the 
new scheme may work in polynomial time. On the other hand, when the scheme is implemented 
using the function ensemble J 71 , supplying the adequate CS-proof (i.e., for (msg, /j(msg)) € R u ) 
only requires polynomial-time (i.e., time polynomial in the time it takes to evaluate /]). This yields 
the following: 

Theorem 4.4 There exists a signature scheme that is existentially unforgeable under a chosen 
message attack in the Random Oracle Model, but such that when implemented with any function 
ensemble, the resulting scheme is existentially forgeable using key-only attack and totally breakable 
under chosen message attack. 



We note again that unlike the "signature scheme" presented in Subsection 4.2 , the signature scheme 
presented below works in polynomial-time. 

Proof: Below we describe such a signature scheme. For this construction we use the following 
ingredients. 

• S = (G, S, V) is a signature scheme, operating in the Random Oracle Model, that is existen- 
tially unforgeable under a chosen message attack. 



A fixed (and easily computable) parsing rule which interpret messages as triples of strings 
msg = (i,s,n). 



The algorithms Prv and Ver of a CS-proof system, as described in Section 2.2 above. 



Access to three independent random oracles. This is very easy to achieve given access to one 
oracle O; specifically, by setting O'(x) = O(01x), 0"(x) = O(10z) and 0"'(x) = O(lls). 

Below we use oracle O'" for the basic scheme S, oracle O" for the CS-proofs, and oracle O' 
for our evasive relation. We note that if O is an £ out -oracle, then so are O' , O" and O'" . 
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• The universal function ensemble U from Subsection ^L^, with proper complexity bound t(n) = 
n logn . We denote by My the universal machine that decides the relation Rr . That is, on 
input ((i, s),y), machine My invokes the z th evaluation algorithm, and accepts if fg((i, s)) = y. 

We note that My works in time t in the worst case. More importantly, if T % is a function 
ensemble that can be computed in time Pi(-) (where pi is some polynomial), then for any 
strings s,y, on input ((i,s),y), machine My works for only poly(|i|) many steps.0 

Using all the above, we describe an ideal signature scheme = (G, S' U ,V^). As usual, the key 
generation algorithm, G, remains unchanged. The signature and verification algorithms proceed as 
follows. 

S4°(sk,msg) d = 

1. Parse msg as (i, s,ir), and set x = (i,s) and y = O'(x). Let n = |(x,y)|. 

2. Apply Ver to verify whether it is a valid CS-proof, with respect to the oracle O" and 
security parameter l n+fc 5 for the claim that the machine My accepts the input (x,y) 
within time t(n). 

(The punch-line is that we do not directly check whether the machine My accepts the 
input (x,y) within time t(n), but rather only if ir is a valid CS-proof of this claim. 
Although t(n) = n logn , this CS-proof can be verified in polynomial-time.) 

3. If 7T is a valid proof, then output (sk, msg). 

4. Otherwise, output S°'" (sk, msg). 

T^°(vk,msg,cr) = f 

1+2. As above 

3. If 7r is a valid proof, then accept 

4. Otherwise, output V° ' (vk, msg, a). 

The computation required in Item 2 of the signature and verification algorithms can be executed 
in polynomial-time. The reason being that (by definition) verifying a CS-proof can be done in 
polynomial-time, provided the statement can be decided in at most exponential time (which is the 
case here since we have t(n) = 0(ra logn )). It is also easy to see that for every pair (sk, vk) output 
by G, and for every msg and every O, the string S^^sk, msg) constitutes a valid signature of msg 
relative to vk and the oracle O. 

To show that the scheme is secure in the Random Oracle Model, we first observe that on 
security parameter l k it is infeasible to find a string x so that (x,0'(x)) € R u , since R u is evasive. 



By Proposition it is also infeasible to find (x,tt) such that (x,0'(x)) Ry and yet ir is a 
valid CS-proof of the contrary relative to O" (with security parameter iM+^°ut(fc)+£^_ Thus, it is 
infeasible for a polynomial-time adversary to find a message that would pass the test on Item 2 of 
the signature/verification algorithms above, and so we infer that the modified signature is secure 
in the Random Oracle Model. 

We now show that for every candidate implementation, there exists a polynomial-time 
adversary effecting total break via a chosen message attack (or, analogously, an existential forgery 
via a "key only" attack). First, for each function f s £ J 7 , denote f' s (x) d = f s (01x), f'J(x) = f s (10x), 
and f' s "(x) = f / s (lla;). Then denote by J-' the ensemble of the f' s functions. 



The point is merely that, for every fixed i, the expression poly(|i|) -pi(|s|) is bounded by a polynomial in |s|. 
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Suppose that T' is the i th function ensemble in the enumeration mentioned above, namely 
T' = J- 1 . Given a randomly chosen fc-bit seed s, the adversary generate a message msg = (i,s,7r) 
so that 7T is a CS-proof (w.r.t the adequate security parameter) for the true statement that Mu 
accepts the input (x,y) within t(\x\ + |y|) steps, where x = (i,s) and y = f' s (x). Recall that the 
above statement is indeed true (since f' s = /]), and hence the adversary can generate a proof for it 
in time which is polynomial in the time that it takes to compute /]. (By the perfect completeness 
property of the CS-proof system, the ability to prove correct statements holds for any choice of 
the random oracle, and in particular when it is equal to f'J.) Since this adversary is specifically 
designed to break the scheme in which the random oracle is implemented by J- , then the index i - 
which depends only on the choice of T - can be incorporated into the program of this adversary. 

By the efficiency condition of CS-proofs, it is possible to find ir (given an oracle access to f'J) 
in time polynomial in the time that it takes Mu to accept the input (x, y). Since T % is polynomial- 
time computable, then Mu works on the input (x,y) = ((i,s),y) in polynomial time, and thus the 
described adversary also operates in polynomial-time. 

By construction of the modified verification algorithm, e is a valid signature on msg = (i, s, ir), 
and so existential forgery is feasible a-priori. Furthermore, requesting the signer to sign the message 
msg yields the signing key, and thus total forgery. I 

Remark 4.5 It is immaterial for the above argument whether CS-proofs can be implemented in 
the "real world" (i.e., without access to random oracles). Specifically, it doesn't matter if one can 
cheat when the oracle is substituted by a candidate function ensemble, as in this case (i.e., in the 
real world implementation) it is sufficient for the adversary to invoke the proof system on valid 
statements. We do rely, however, on the perfect completeness of CS-proofs that implies that valid 
statements can be proven for any possible choice of oracle used in the proof system. 



4.4 Encryption 

The construction presented for signature schemes can be adapted to public-key encryption schemes 
in a straightforward way, yielding the following theorem^ 

Theorem 4.6 

(a) Assume that there exists a public key encryption scheme that is semantically secure in the 

Random Oracle Model. Then there exists a public key encryption scheme that is semantically 
secure in the Random Oracle Model but is not semantically secure when implemented with 
any function ensemble^ 

(b) Assume that there exists a public key encryption scheme that is secure under adaptive chosen 

ciphertext attack in the Random Oracle Model. Then there exists a scheme that is secure 
under adaptive chosen ciphertext attack in the Random Oracle Model, but implementing it 
with any function ensemble yields a scheme that is not semantically secure, and in which a 
chosen ciphertext attack reveals the secret decryption key. 



Proof: In this proof we use the same notations as in the proof of Theorem 44. Let £ = (G, E, D) 



be an encryption scheme that is semantically secure in the Random Oracle Model, and we modify 



13 Similarly, we can adapt the argument to shared-key (aka private-key) encryption schemes. See Remark 4.£ 



14 Here we refer to semantic security as defined by Goldwasser and Micali in |15[, and not to the seemingly weaker 
definition presented in [[til, ll^l • Goldwasser and Micali allow the message space to depend on the public-key, whereas 
this is not allowed in 
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it to get another scheme £' = (G, E' , D'). The key generation algorithm remains unchanged, and 
the encryption and decryption algorithms utilize a random oracle O, which is again viewed as three 
oracles 0',0" and O'" . 

Modified encryption, £'g k C '(msg), of plaintext msg using the public encryption-key ek: 

1. Parse msg as (i,s,ir), set x = (i,s) and y = O'(x), and let n = |(x,y)|. 

2. If 7r is a valid CS-proof, w.r.t oracle O" and security parameter l n + fc 5 for the assertion 
that My accepts the pair (x,y) within t(n) steps, then output (l,msg). 

3. Otherwise (i.e., tt is not such a proof), output (2, ^^'"(msg)). 
Modified decryption, D' dk °(c), of ciphertext c using the private decryption-key dk: 

1. If c = (1, d), output d and halt. 

2. If c = (2,c'), output £>&"'(</) and halt. 

3. If c = (3, d) then parse d as (i, s, tt), and set x = (i, s), y = O'(x), and n = \(x,y)\. If tt 
is a valid CS-proof, w.r.t oracle O" and security parameter for the assertion that 
Mu accepts the pair (x, y) within t(n) steps, then output dk and halt. 

4. Otherwise output e. 

The efficiency of this scheme follows as before. It is also easy to see that for every pair (ek, dk) 
output by G, and for every plaintext msg, the equality D' dk (E' ck (msg)) = msg holds for every 
O. To show that the scheme is secure in the Random Oracle Model, we observe again that it 
is infeasible to find a plaintext that satisfies the condition in Item 2 of the encryption algorithm 
(resp., a ciphertext that satisfies the condition in Item 3 of the decryption algorithm). Thus, the 
modified ideal encryption scheme (in the Random Oracle Model) inherits all security features of 
the original scheme. 

Similarly, to show that replacing the random oracle by any function ensemble yields an insecure 
scheme, we again observe that for any such ensemble there exists an adversary who - given the 
seed s - can generate a plaintext msg (resp., a ciphertext c) that satisfies the condition in Item 2 
of the encryption algorithm (resp., the condition in Item 3 of the decryption algorithm). Hence, 
such an adversary can identify when msg is being encrypted (thus violates semantic security), or 
ask for a decryption of c, thus obtaining the secret decryption key. H 



Remark 4.7 As opposed to Theorem 4.4, here we need to make computational assumptions, 
namely, that there exist schemes that are secure in the Random Oracle Model. (The result in 
imply that it is unlikely that such schemes are proven to exists without making any assumptions.) 
Clearly, any scheme which is secure without random oracles is also secure in the Random Oracle 



Model. Recall that the former exist, provided trapdoor permutations exist [TLa, 29]. 



Remark 4.8 The constructions presented above can be adapted to yield many analogous results. 
For example, a result analogous to Theorem 4.6 holds for shared-key (aka private-key) encryption 
schemes. In this case no computational assumptions are needed since secure shared-key encryption 
is known to exist in the Random Oracle Model. Similarly, we can prove the existence of a CS-proof 
in the Random Oracle Model that has no implementations (via any function ensemble). In fact, as 
remarked in the Introduction, the same technique can be applied to practically any cryptographic 
application. 
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5 Restricted correlation intractability 



Faced with the negative result of Theorem |3.4| , one may explore restricted (and yet possibly useful) 
versions of the correlation intractability property. One possibility is to put more stringent con- 
straints on the use of the ensemble in a cryptographic scheme, and then to show that as long as 
the ensemble is only used in this restricted manner, it is guaranteed to maintain some aspects of 
correlation intractability. 



In particular, notice that the proof of Theorem 3.4 relies heavily on the fact that the input to 
f s can be as long as the seed s, so we can let the input to the function f s be equal to s. Thus, one 
option would be to require that we only use f s on inputs that are shorter than s. Specifically, we 
require that each function f s will only be applied to inputs of length ^i n (|s|), where £- m : N— >N is 
some pre-specified function (e.g. £\ n {k) = k/2). The corresponding restricted notion of correlation 
intractability is derived from Definition |3^ : 

Definition 5.1 (restricted correlation intractability) Let£i n ,£ out : N— >N be length functions. 
A machine M is called (^-respecting if \M(s)\ = £i n (\s\) for all s € {0, 1}*. 

• A binary relation R is evasive with respect to (£m,£out) if for any £- m -respecting probabilistic 
polynomial-time oracle machine M 

Pr[x <- M°(l k ), ( X ,0(x))eR] = negl(fc) 

where O : {0, l}^ in ( fc ) — > {0, l}^° ut ( fc ) is a uniformly chosen function and negl(-) is a negligible 
function. 

• We say that an £ ovAi - ensemble T is (£- m , £ out )-restricted correlation intractable (or just & m - 
correlation intractable, for short), if for every l- m -respecting probabilistic polynomial-time 
machine M and every evasive relation R w.r.t. (£m,4>ut); it holds that 

Pr [x <- M(s), (x, f s {x)) €R] = negl(fc) 

Weak ^in-correlation intractability is defined analogously by considering only polynomial-time rec- 
ognizable R's. 

The rest of this section is dedicated to demonstrating impossibility results for restricted corre- 
lation intractable ensembles, in some cases. We also highlight cases where existence of restricted 
correlation intractable ensembles is left as an open problem. 



5.1 Negative results for short seeds 



The proof ideas of Theorem can be easily applied to rule out the existence of certain restricted 
correlation intractable ensembles where the seed is too short. 



Proposition 5.2 

(a) If £i n (k) > k — O(logfc) for infinitely many k's, then there exists no ensemble that is (An>4mt)- 

correlation intractable, even in the weak sense. 

(b) If £m(k) + £ nt(k) > k + u>(logk), there exists no ensemble that is (£- m , £ ou t) -correlation in- 

tractable. 
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Proof: The proof of (a) is a straightforward generalization of the proof of Theorem ^OJ. Actually, 
we need to consider two cases: the case £m(k) > k and the case k — 0(log k) < £i n (k) < k. In the 

first case, we proceed as in the proof of Theorem |3.4| (except that we define R? = f {(x, f s (x)) ■ s G 
{0, l}*,x = s0^"(l s l)-l s l}). In the second case, for every ensemble we define the relation 

R T = {(x, f xz (x)) :x,ze {0, 1}* , \x\ = £ in (\xz\)} 

We show that R? is evasive by showing that, for every k G N and x G {0, lY in ^ k \ there exist at 
most polynomially (in k) many y's such that (x, y) G R? '. This is the case since (x, y) G R^ implies 
that there exists some z such that And^l) = \x\ an d V = fxz(x)- But using the case hypothesis 
we have \x\ = £- m (\xz\) > \xz\ — 0(log \xz\), which implies that \z\ = OQog(\xz\)) and hence also 
\z\ = 0(log|x|). Next, using the other case hypothesis (i.e., k > £\ n {k) = we conclude that 
\z\ = 0{\ogk). Therefore, there could be at most polynomially many such z's, and so the upper 
bound on the number of y's paired with x follows. The evasiveness of RF as well as the assertion 
that R? is polynomial-time computable follow (assuming that the function £- m itself is polynomial- 
time computable). On the other hand, consider the machine M that, on input s, outputs the 
4n(|s|)-bit prefix of s. Then, for every s G {0, 1}*, we have (M(s), f s (M(s))) G R F . 

For the proof of (b), assume that £- m (k) < k (for all but finitely many k's). We start by defining 
the "inverse" of the £- iri function 

?fa(n) = f min{/c : £- m {k) = n} 

(where, in case there exists no k such that £i n (k) = n, we define £^ (n) = 0). By definition it 
follows that k > £^ (£i n (k)), for all fc's (because k belongs to the set {k 1 : £- m (k') = £- m (k)}), and 
that £m{£\^~ { n )) = n , whenever there exists some k for which n = £- m (k). Next we define 

R T = {(x, f xz {x)) :x,ze {0, 1}* , \x\ + \z\ = C(M)} 

This relation is well defined since, by the conditions on the lengths of x and z, we have ^in(|a^|) = 
£i n (£jn L (|x|)) = | a; | and so the function f xz is indeed defined on the input x. In case £- m (k) < 
k — o;(logfc), this relation may not be polynomial-time recognizable. Still, it is evasive w.r.t. 
(^inj^out)j since with security parameter k we have for every x £ {0, l}^ in ( fc ) 

{t/e{0,lf-W :(x,y)eR :F }\ = \{f xz (x) : \z\ = £r l (£ in (k)) - £ m (k)} n {0,1}*»*W 

Using k — £\ D (k) < £ OVL t(k) — w(log k), we conclude that the set of y's paired with x forms a negligible 
fraction of {0, l}^° ut ( fc ) ; and so that R? is evasive. Again, the machine M, that on input s outputs 
the 4,(|s|)-bit prefix of s, satisfies (M(s), f s (M(s))) G R T , for all s's. ■ 



Open Problems: Proposition 5.2 still leaves open the question of existence of (£- m , ^ ou t)-restricted 
correlation intractable ensembles, for the case £- m (k) + £ ut(k) <k + 0(log We believe that it 
is interesting to resolve the situation either way: Either provide negative results also for the above 

In fact such ensembles do exist in case k > 2 £i » (fc) • e out (k) (since the seed may be used to directly specify all the 
function's values), but we dismiss this trivial and useless case. 
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special case, or provide a plausible construction. Also open is the sub-case where £- m (k) + £ ou t(k) = 
k + Ld(logk) but one considers only weak (£j n , £ out )-restricted correlation intractability. (Recall that 



Case (b) of Proposition 5.2 is proven using relations which are not known to be polynomial-time 
recognizable.) 

We comment that even if restricted correlation intractable ensembles exist, then they are very 
non-robust constructs. For example, even if the ensemble T = {f s : \s\ = k} k is correlation in- 
tractable with respect to some length functions {£\ a , £ ut), the ensemble that is obtained by applying 
many independent copies of T and concatenating the results may not be. That is, for m : N — > N, 
define 

F m = {f( Sl ,...,s m(k) ) : hi = • • • = \ s m(k) \ = k}keN , (2) 
where, for (x u x m{k) ) € {0, l} m « •*»(*>, 

f{si,...,s m(k) )({ x l>-> x m(k))) = f (fs 1 (xi),....,fs rn(k) (x m{k) )) . (3) 

Then, for sufficiently large m (e.g., m(k) > k/£- in {k) will do), the "direct product" ensemble T m is 
not correlation intractable (not even in the restricted sense). That is, 

Proposition 5.3 Let Aru^out : N— >N be length functions so that £i n (k) < k, and let m : N— >N be 
a polynomially-bounded function so that m(k) > k/£- m {k). Let F be an arbitrary function ensemble, 
and J-™ 1 be as defined in Eq. (^) and (^). Then, T m is not correlation intractable, not even in the 

(•^,^ut) -restricted sense, where £\^(m(k) ■ k) = f m(k) ■ l- m {k) and £^ t (m(k) ■ k) = f m(k) ■ £ ut(k). 
Proof: We assume, for simplicity that m(k) = k/£i n (k) (and so ^m(^) = k/m(k) and £^(m(k)-k) = 



k). Given T m as stated, we again adapt the proof of Theorem 3A This time, using £\ n {k) < k, we 
define the relation 

R rm = (J { (s, (f s {s'),t)) : \s\ = k, s' is the £ in (A;)-prefix of s, \t\ = (m{k) - 1) • £ out (k) } 

k 

Notice that in this definition we have |s| = |ttct ■ £'m(k) = m(k) ■ £i n {k) = £l™(m(k) ■ k), and also 
|/ s (s')| + \t\ = m(k) ■ £ ou t(k) = £™ nt (m(k) ■ k), so this relation is indeed (£^, £™ t )-restricted. 

Again, it is easy to see that is polynomial-time recognizable, and it is evasive since every 
string x € {0, l} k is coupled with at most a 2~^ out ( fc ) fraction of the possible (m(k) ■ £ OVLt (k))-bit long 
strings, and £ ut(k) = co(log k) = u>(log(m(k) ■ k)). (Here we use the hypothesis m(k) = poly(/c).) 

On the other hand, consider a (real-life) adversary that given the seed s = (s\, s m ( k \) € 
{0, l} m ( fc )' fc for the function ft N , sets the input to this function to be equal to s±. Denoting 

the ^i n (fc)-prefix of si (equiv., of s) by s[, it follows that f Sl (s'i) is a prefix of f'^ s {k) )( s i) an d 
so (si,/^ si s (fc) )( s i)) G • Thus, this real-life adversary violates the (restricted) correlation 
intractability of J- m 



5.2 Correlation intractability for multiple invocations 



Recall that Proposition |5.2| does not rule out the existence of restricted ensembles having seeds 
that are longer than the sum of lengths of their inputs and outputs. However, even for this 
special case the only thing that is not ruled out is a narrow definition that refers to forming 
rare relationships between a single input-output pair. In fact, if one generalizes the definition of 
correlation intractability so as to consider evasive relations over unbounded sequences of inputs 



and outputs, then the negative result in Proposition ^2| can be extended for arbitrary £- m and £ ou t. 
That is, 
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Definition 5.4 (multi-invocation restricted, correlation intractability) Let £- 1Xi , £ on i : 

be length functions. We consider probabilistic polynomial-time oracle machines which on input 1 

have oracle access to a function O : {0, — > {0, l}^° ut ( fc ). 

• A relation R over pairs of binary sequences is evasive with respect to (£m,4>ut) (or (£m,£ OVl t)- 
evasive) if for any probabilistic polynomial-time machine M as above it holds that 



Pr 

o 



f Tl r )^M°(l k )- \ x i\ - ■ ■ ■ - \ x m\ - ?m(k) 



negl(/c) 



As usual, O : {0, l}^ in ( fc ) — > {0, l}^ out ( fe ) is a uniformly chosen function. 



We say that an £ out -ensemble T is (£- in , £ ou t)-restricted multi-invocation correlation intractable 
(or just £i n -multi-invocation correlation intractable, /or short), if for every (£{ n , £ out )-evasive 
relation R and every probabilistic polynomial-time machine M it holds that 



Pr 

se{o,i} fe 



(xt, ...,x m ) «- M(s) ; 



x i\ 



and ((xi, ...,x m ), (f s (xi), f s (x m ))eR 



negl(fc) 



Proposition 5.5 Let ^i n ,^out : N^N be arbitrary length functions, with £m(k) > 2 + log A; and 
^out(^) > 1- r/ien i/iere exist no {£- m , 4mt) -restricted multi-invocation correlation intractable func- 
tion ensembles. 



Proof: For simplicity, we consider first the case £ ut{k) > 2. Let T be an £ out -ensemble. Adapting 
the proof of Theorem |3.4|, we define the relation 



R 



T def 



|J <^ ((Xi, . . . ,X k ), (/ s (xi), . . .,f s (Xk))) ■ 



{i,Si), with Si e {0, 1} 



and s = s\ . . . s k 



(Notice that since £- m {k) > 1 + logfc, the x^'s are indeed in the range of the function f s .) Clearly, 
this relation is polynomial-time recognizable. To see that this relation is evasive, notice that for 
any fixed fe-bit seed s = s\ . . . s k , we have 



Pr[C(i, Si ) = f.(i, Si ) for i = 1 . . . k] = 2 



■^out (&) 



Hence, the probability that there exists a seed s for which 0(i, S{) = f s (i, Si) holds, for i = l, k, 
is at most 2 k ■ 2~ e ™ t( - k > k < 2~ k . It follows that 



Pr[3 Xl ,...,x k ((x 1 ,...,x k ),(0(x 1 ),...,0(x k ))) £ R^} < 2~ k 

However, the corresponding multi-invocation restricted correlation intractability condition does not 
hold: For any s = s% . . . s k G {0, l} fc , setting x { = (i,Si) we get ((x x , ...,x k ), (/ s (xi), f s (x k ))) € 
R T . 

To rule out the case £ vx{k) = 1, we redefine R? so that ((xi, X2 k ), (f s (xi), f s {x2 k ))) G R T 
if Xi = (i, Si) for i = 1, k and Xi = (i, 0) for i = k + 1, 2k. ■ 
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Discussion: Propositions |5.2| , 5.3 and |5.5| demonstrate that there is only a very narrow mar- 
gin in which strict correlation-intractability may be used. Still, even ensembles that are (strict) 
correlation-intractable with respect to relations of a-priori bounded total length (of input-output 
sequences) may be useful in some applications. Typically, this may hold in applications where 
number of invocations of the cryptosystem is a-priori bounded (or where the security of the system 
depends only on an a-priori bounded partial history of invocations; e.g., the current one). We note 
that the Fiat-Shamir heuristic for transforming interactive identification protocols into signature 
schemes j|] does not fall into the above category, since the function's seed needs to be fixed with the 
public key, and used for signing polynomially many messages, where the polynomial is not a-priori 
known. 



5.3 Correlation intractability for given, polynomial-time relations 

In all our negative results, the evasive relation demonstrating that a certain function ensemble is 
not correlation-intractable is more complex than the function ensemble itself. A natural restriction 
on correlation-intractability is to require that it holds only for relations recognizable within certain 
fixed polynomial time bounds (or some fixed space bound), and allowing the function ensemble to 
have a more complex polynomial-time evaluation algorithm. We stress that, in both the definition 
of evasiveness and correlation-intractability, the adversary that generates the inputs to the relation 
is allowed arbitrary (polynomial) running time; this time may be larger than both the time to 
evaluate the function ensemble and the time to evaluate the relation. Such a restricted notion of 
correlation- intractability may suffice for some applications, and it would be interesting to determine 
whether function ensembles satisfying it do exist. Partial results in this direction were obtained by 
Nissim p4[ | and are described next: 

Proposition 5.6 (||24|j) Let £i n ,£ ut '■ N— >N be arbitrary length functions, with k > £ ou t(k) ■ 
(£m(k) + w(log k)) j^j Then, for every binary relation R that is evasive with respect to (An,^out) an d 
recognizable in polynomial-time, there exists a function ensemble J- R = {f s } that is correlation- 
intractable with respect to R; that is, for every £[ n -respecting probabilistic polynomial-time machine 
M it holds that 

Pr [x <- M(s), (x, Ux)) e R] = negl(fc) 

sG{0,l} fe 



We note that the postulated construction uses a seed length that is longer than £[ Q + £ ont . Thus, 
this positive result capitalizes on both restrictions discussed above (i.e., both the length and the 
complexity restrictions). 

Proof: Let t = £- m (k) + uj (log k). For every seed s = (s\,...,s t ) G {0,l} te ° nt ^ k \ we define 
f s : {0, l}^n( fc ) — > {0, l} £ °ut( fc ) so that f Sl ,...,s t { x ) equals Sj if i is the smallest integer such that 
(x, Si) G" R. In case (x,s«) G R holds for all i's, we define f si ,...,s t ( x ) arbitrarily. 

Let R(x) d = {y : (x,y) G R}, and S k d = {x G {0,l} £ -( fc ) : \R(x)\ < 2^( fc )/2} (S stands for 
"Small image"). Since R is evasive, it is infeasible to find an x G {0, not in Sk- Thus, for 

every probabilistic polynomial-time M, Pr se |o ) i}fc[M(s) S^] = negl(fc). On the other hand, the 
probability that such M(s) outputs an x G so that (x, f s (x)) G R is bounded above by^] 

Pr [3x G Sk s.t. (x, f s (x)) G R] < Pr [3x G Sk Vi (x, Sj) G R] 
se{o,i} k se{o,i} fe 

16 Recall that (£- ln , f ou t)-restricted correlation- intractable ensembles exist for k > 2 fin( - fe - ) • £ ou t(k); see Footnote 

17 For the first inequality, we use the fact that if there exists an i such that (x, st) R then (x, fs(x)) £ R. 
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< |<Sjfe| -max jPr[Vz (x, Sj) G 

< 2 ^"( fc ) • (1/2)* = negl(jfe) 



Combining the two cases, the proposition follows. H 

Considering the notion of multi-invocation correlation-intractability when restricting the com- 
plexity of the relation (and allowing the function ensemble to be more complex), Nissim has obtained 
another impossibility result [p4j[: 



Proposition 5.7 ( ||24[| ) There exists an evasive relation R that is recognizable in polynomial-time 
so that no function ensemble T = {f s } is multi-invocation correlation-intractable with respect to R; 
that is, for every function ensemble J- = {f s } there exists a polynomial-time machine M such that 

Pr[(si,...,x t )«-M(«); (( Xl , x t ), (f s ( Xl ), f s (x t )) e R] = 1 
Furthermore, for some universal polynomial p, which is independent of J- , it holds that t < p(\x\\). 



We stress that the above assertion includes even function ensembles that have (polynomial-time) 
evaluation algorithms of running time greater than the time it takes to recognize i-tuples of corre- 
sponding length is the relation. Furthermore, it includes function ensembles having seeds of length 
exceeding the total length of pairs in the relation. 



Proof Sketch: We follow the ideas underlying the proof of Theorem 4.4. Specifically, using the 
universal machine Mu and the algorithms (Prv and Ver) of a CS-proof system, we consider a 
relation R that contains pairs of binary sequences, so that (( X ,ir,qi...,q m ), (y,<j>,ai...,a m )) G R if 
these strings describe an accepting execution of the CS-verifier with respect to machine My. That 
is, we require that the following conditions hold: 

1. All the strings y,(f),a%...,a m have the same length. Below we denote this length by 4,ut> 

\\)\ = |0| = l Q l| = • • • = \ a m\ = Lut- 

2. The string it is an alleged CS-proof for the assertion that the machine Mu accepts the input 
(x,y) within t[n) = n logn steps, where n = f \x\ + \y\. 

3. Given access to an oracle that on queries qi returns answers a^, and given security parameter 
n + 4>ut and input w = {(Mu), (x, y),t(n)), the CS verifier Ver accepts the CS-proof n after 
querying the oracle on q\...q m (in this order), and obtaining the corresponding answers 
ai . . . a m . 

(Here we use the fact that the verifier is deterministic, and thus its queries are determined 
by its input and the answers to previous queries.) 

Recall that, by definition, m is bounded by a fixed polynomial in n. In fact, in Micali's con- 



struction [21 1, m is poly-logarithmic in n. We comment that, assuming the existence of suitable 
collision-intractable hash functions, one may obtain m = 1 (cf. p^] . In addition, one may need to 
make some minor modification in the above construction.) 



As in the proof of Theorem 4.4, using the computational soundness of CS-proofs, it can be shown 



that the above relation is evasive. By the additional efficiency conditions of CS-proofs, it follows that 



the relation is recognizable in polynomial-time. On the other hand, as in the proof of Theorem 4.4 



for every function ensemble T l = {/]} there exists a polynomial-time adversary A, that on input s 
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produces a sequence (x, it, q 1 , q m ) so that ((x, it, q ± , q m ), (f l s (x), /](tt), P s (qi), P s {q m ))) G 
This is done as follows: First A sets x = (i,s), y = f l s {x), and n = f \x\ + \y\. Next, A constructs a 
CS-proof that indeed My accepts (x, y) within n log ™ steps, and sets ir to equal this proof. (This step 
takes time polynomial in the evaluation time of p s {x).) Note that since (x, y) is indeed accepted by 
Mu (in less than n log n steps) , the verifier accept it as a proof no matter how the oracle is determined 
(since perfect completeness holds). Finally, the adversary invokes the verifier (on input consisting 
mainly of (x,y) and 7r), and (by emulating the oracle) determines interactively the oracle queries 
and answers of the verifier; that is, for every j = 1, ...,m, the adversary determines the j th query 
made by the verifier, sets qj to equal this query, and provides the verifier with the answer fl(qj). 
□ 

6 Conclusions 

The authors have different opinions regarding the Random Oracle Methodology. Rather than trying 
to strike a mild compromise, we prefer to present our disagreements in the most controversial form. 

6.1 Ran's Conclusions 

Real-life cryptographic applications are complex objects. On top of the "cryptographic core," 
these applications typically involve numerous networking protocols, several other applications, user- 
interfaces, and in fact also an entire operating-system. The security of an application depends on 
the security of all these components operating in unison. Thus, in principle, the best way to gain 
assurance in the security of a cryptographic application is to analyze it as a single unit, bones and 
feathers included. 

However, analyzing an entire system is prohibitively complex. Moreover, we often feel that 
the "essence" of a cryptographic application can be presented in a relatively simple way without 
getting into many details, which, we feel, are "extraneous" to the actual security. Consequently, 
we often make abstractions of a cryptographic application by leaving many details "outside the 
model" . Nonetheless, some caution is needed when making abstractions: While good abstractions 
are important and useful, bad abstractions can be dangerous and misleading. Thus, it is crucial to 
make sure that one uses a sound abstraction, or one that helps to distinguish between good and 
bad applications. 

One popular abstraction is to treat computers in a network as interactive Turing machines 
who run one specific (and relatively simple) algorithm, and assume that delivery of messages is 
done simply by having one machine write values on the tapes of another machine. We are then 
satisfied with defining and analyzing security of a protocol in this abstract model. In other words, 
this abstraction implicitly uses the following methodology (which I'll call the "Interactive Turing 
machine methodology"): Design and analyze a protocol in the "idealized system" (i.e., using Turing 
machines). Next, come up with an "implementation" of the idealized protocol by adding the 
components that deal with the networking protocols, the operating system, the user interfaces, etc. 
Now, "hope" that the implementation is indeed secure. 

We widely believe that this methodology is sound, in the sense that if an idealized protocol is 
secure then there exist secure implementations of it. Furthermore, security of an idealized protocol 
is a good predictor for the feasibility of finding a good implementation to it. (Of course, finding 
secure implementations to secure idealized protocols is a far-from-trivial task, and there is probably 
no single automatic method for securely implementing any idealized protocol. But this does not 
undermine the soundness of the "Interactive Turing machine methodology".) 



25 



The Random Oracle Methodology is, in essence, another proposed abstraction of cryptographic 
applications. It too proposes to define and analyze security of protocols in an idealized model, then 
perform some transformation that is "outside the formal model" , and now "hope" that the resulting 
implementation is secure. At first glance it looks like a great abstraction: It does away with specific 
implementation issues of "cryptographic hash functions" and concentrates on designing protocols 
assuming that an "ideal hash function" is available. Indeed, protocols that were designed using 
this methodology are remarkably simple and efficient, while resisting all known attacks. 

However, as shown in this work, and in sharp contrast to the "Interactive Turing machine 
methodology" , the Random Oracle Methodology is not sound. Furthermore, it is a bad predictor 
to the security of implementations: Not only do there exist idealized protocols that have no secure 
implementations, practically any idealized protocol can be slightly "tweaked" so that the tweaked 
protocol remains just as secure in the idealized model, but has no secure implementations. This 
leaves us no choice but concluding that, in spite of its apparent successes, the Random Oracle 
Methodology is a bad abstraction of protocols for the purpose of analyzing security. 

The loss of reductions to hard problems. The above argument should provide sufficient 
motivation to be wary of security analyses in the Random Oracle Model. Nonetheless, let us 
highlight the following additional disturbing aspect of such analysis. 

One of the great contributions of complexity-based modern cryptography, developed in the past 
quarter of a century, is the ability to base the security of many varied protocols on a small number of 
well-defined and well-studied complexity assumptions. Furthermore, typically the proof of security 
of a protocol provides us with a method for transforming adversary that breaks the security of the 
said protocol into an adversary that refutes one of the well-studied assumptions. In light of our 
inability to prove security of protocols from scratch, this methodology provides us with the "next 
best" evidence for the security of protocols. 

The Random Oracle Methodology does away with these advantages. Assume that an idealized 
protocol A is proven secure in the Random Oracle Model based on, say, the Diffie-Hellman assump- 
tion, and that someone comes up with a way to break any implementation of A. This does not 
necessarily mean that it is now possible to break Diffie-Hellman! Consequently, the reducibility 
of the security of A to the hardness of Diffie-Hellman is void. This brings us back to a situation 
where the security of each protocol is a "stand-alone" problem and is, in essence, unrelated to the 
hardness of known problems. 

Possible alternative directions. In spite of its shortcomings, the Random Oracle Methodology 
seems to generate simple and efficient protocols against which no attacks are known. One possible 
direction towards providing formal justification for some of these protocols is to identify useful, 
special-purpose properties of the random oracle, which can be also provided by a fully specified 
function (or function ensemble) and so yield secure implementations of certain useful ideal systems. 
First steps in this direction were taken in j|, |To|| . Hopefully, future works will push this direction 
further. 

6.2 Oded's Conclusions 

My starting point is that within the domain of science, every deduction requires a rigorous justifica- 
tion.^ In contrast, unjustified deductions should not be allowed; especially not in a subtle research 

18 This does not disallow creative steps committed in the course of research, without proper justification. Such 
unjustified steps are the fuel of progress. What I refer to are claims that are supposed to reflect valid facts. Such 
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area such as Cryptography. Furthermore, one should refrain from making statements that are likely 
to mislead the listener /reader, such as claiming a result in a restricted model while creating the 
impression that it holds also in a less restricted model. The presentation of such a result should 
clearly state the restrictions under which it holds, and refrain from creating the impression that the 
result extends also to a case where these restrictions are waived (unless this is indeed true (and one 
can prove it)). Needless to say, it is perfectly OK to conjecture that a restricted result extends also 
to a case when these restrictions are waived, but the stature of such a statement (as a conjecture) 
should be clear. 

The above abstract discussion directly applies to security in the Random Oracle Model. Deduc- 
ing that the security of a scheme in the Random Oracle Model means anything about the security 
of its implementations, without proper justification, is clearly wrong.0 This should have been clear 
also before the current work. It should have also been clear that no proper justification of deduction 
from security in the Random Oracle Model to security of implementations has been given (so far). 
The contributions of the current work are two-fold: 

1. This work uncovers inherent difficulties in the project of providing conditions that would allow 
(justifiable) deduction from security in the Random Oracle Model to security of implementa- 
tions. Such a project could have proceeded by identifying properties that characterize proofs 
of security in the Random Oracle Model, and (justifiably) deducing that the such schemes 
maintain their security when implemented with ensembles satisfying these properties. The 
problem with this project is that correlation intractability should have been (at the very least) 
one of these properties, but (as we show) no function ensemble can satisfy it. 

2. As stated above, deducing that the security of a scheme in the Random Oracle Model means 
anything about the security of its implementations, without proper justification, is clearly 
wrong. The current work presents concrete examples in which this unjustified deduction 
leads to wrong conclusions. That is, it is shown that not only that unjustified deduction 
regarding the Random Oracle Model MAY lead to wrong conclusions, but rather than in some 
cases INDEED this unjustified deduction DOES lead to wrong conclusions. Put in other words, 
if one needs a concrete demonstration of the dangers of unjustified deduction when applied 
to the Random Oracle Model, then this work provides it. 

The bottom-line: It should be clear that the Random Oracle Methodology is not sound; that 
is, the mere fact that a scheme is secure in the Random Oracle Model cannot be taken as evidence 
(or indication) to the security of (possible) implementations of this scheme. Does this mean that 
the Random Oracle Model is useless? Not necessarily: it may be useful as a test-bed (or as a sanity 
check) .0 Indeed, if the scheme does not perform well on the test-bed (resp., fails the sanity check) 
then it should be dumped. But one should not draw wrong conclusions from the mere fact that a 
scheme performs well on the test-bed (resp., passes the sanity check). In summary, the Random 
Oracle Methodology is actually a method for ruling out some insecure designs, but this method is 
not "complete" (i.e., it may fail to rule out insecure designs) .0 

claims should be fully justified, or offered as conjectures. 

19 Using the Random Oracle Model as a justification to the feasibility of meeting some security requirements is 
even "more wrong". 

20 This explains the fact the Random Oracle Methodology is in fact used in practice. In also explains why many 
reasonable schemes, the security of which is still an open problem, are secure in the Random Oracle Model: good 
suggestions should be expected to pass a sanity check. 

21 Would I, personally, endorse this method is a different question. My answer is very much time-sensitive: Given 
the current misconceptions regarding the Random Oracle Model, I would suggest not to include, in currently published 
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6.3 Shai's Conclusions 



The negative results in this work (and in particular Theorems 4.4 and 4.6) leave me with an uneasy 



feeling: adopting the view that a good theory should be able to explain "the real world" , I would 
have liked theoretical results that explain the apparent success of the random oracle methodology 
in devising useful, seemingly secure, cryptographic schemes. (Indeed, this was one of the original 
motivations for this work.) Instead, in this work we show that security of cryptographic schemes 
in the Random Oracle Model does not necessarily imply security in "the real world". Trying to 
resolve this apparent mismatch, one may come up with several different explanations. Some of 
those are discussed below: 

• The current success of this methodology is due to pure luck: all the current schemes that are 
proven secure in the Random Oracle Model, happen to be secure also in the "real world" for 
no reason. However, our "common sense" and sense of esthetics must lead us to reject such 
explanation. 

• The current apparent success is a mirage: some of the schemes that are proven secure in the 
Random Oracle Model are not really secure, and attacks on them may be discovered in the 
future. 

This explanation seems a little more attractive than the previous one. After all, a security 
proof in the Random Oracle Model eliminates a broad class of potential attacks (i.e., the ones 
that would work also in the Random Oracle Model), and in many cases it seems that attacks 
of this type are usually the ones that are easier to find. Hence, it makes sense that if there 
exists a "real life" attack on a scheme which is secure in the Random Oracle Model, it may be 
harder - and take longer - to find this attack. Still, the more time passes without published 
attacks against "real life" schemes which are proven secure in the Random Oracle Model, the 
less likely this explanation would become. 

• Another possible explanation is that the random oracle methodology works for the current 
published schemes, due to some specific features of these schemes that we are yet to identify. 
That is, maybe it is possible to identify interesting classes of schemes, for which security in 
the Random Oracle Model implies the existence of a secure implementation]^] 

Identifying such interesting classes, and proving the above implication, is an important - and 
seemingly hard - research direction. (In fact, it even seems to be hard to identify classes 
of schemes for which this implication makes a reasonable computational assumption.) To 
appreciate the difficulty in proceeding towards this goal, recall that the techniques in the 
work can be used to "tweak" almost any cryptographic scheme into one which is secure in the 
Random Oracle Model but has no secure implementation. Hence, any classification as above 
must be refined enough to separate the original scheme (for which we want to prove that 
security in the Random Oracle Model implies security in the real world) from the "tweaked" 
one (for which this implication does not hold). 

My bottom line is that at the present time, the random oracle methodology seems to be a 
very useful "engineering tool" for devising schemes. As a practical matter, I would much rather 

work, proofs of security in the Random Oracle Model. My rationale is that the dangers of misconceptions (regarding 
such proofs) seem to out-weight the gain of demonstrating that the scheme passed a sanity check. I hope that in the 
future such misconceptions will be less prevailing, at which time it would be indeed recommended to report on the 
result of a sanity check. 

22 One particularly silly example are schemes that do not use the oracle. Another, more interesting example, are 
schemes that only use the "perfect one-way" property of the oracle; see W, H|. 
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see today's standards built around schemes which are proven secure in the Random Oracle Model, 
than around schemes for which no such proofs exist. The results in this paper, however, must serve 
as a warning that security proof in the Random Oracle Model can never be thought of as the end 
of the road. Proofs in the Random Oracle Model are useful in that they eliminate a broad class of 
attacks, but they do not imply that other attacks cannot be found. 

In terms of scientific research, our works clearly demonstrate that the random oracle method- 
ology is not sound in general. My feeling is that our understanding of the relations between the 
Random Oracle Model and the "real world" is very limited. As I said above, it would be very 
interesting to identify special cases in which the random oracle methodology is sound. Similarly, it 
would be interesting to see other, "less artificial", examples where this methodology fails. 
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